IBIS Macromodel Task Group

Meeting date: 09 August 2022

Members (asterisk for those attending):
Achronix Semiconductor:       Hansel Dsilva
Amazon:                       John Yan
ANSYS:                      * Curtis Clark
                            * Wei-hsing Huang
Cadence Design Systems:       Ambrish Varma
                              Jared James
Google:                       Zhiping Yang
Intel:                      * Michael Mirmak
                            * Kinger Cai
                            * Chi-te Chen
                              Alaeddin Aydiner
Keysight Technologies:        Fangyi Rao
                              Majid Ahadi Dolatsara
                            * Ming Yan
                              Radek Biernacki
                              Rui Yang
Luminous Computing            David Banas
Marvell                       Steve Parker
Mathworks (SiSoft):         * Walter Katz
                              Mike LaBonte
Micron Technology:          * Randy Wolff
                            * Justin Butterfield
Missouri S&T                  Chulsoon Hwang
SAE ITC                       Michael McNair
Siemens EDA (Mentor):       * Arpad Muranyi
Teraspeed Labs:             * Bob Ross
Zuken USA:                    Lance Wang

The meeting was led by Arpad Muranyi.  Curtis Clark took the minutes.

--------------------------------------------------------------------------------
Opens:

- None.

-------------
Review of ARs:

- None.

--------------------------
Call for patent disclosure:

- None.

-------------------------
Review of Meeting Minutes:

Arpad asked for any comments or corrections to the minutes of the July 26th
meeting.  Michael moved to approve the minutes.  Randy seconded the motion.
There were no objections.

--------------
New Discussion:

Proposal for a new keyword: [Clock Group]
Michael reviewed the [Clock Group] BIRD draft he had recently emailed to the ATM
list.  He said this proposal was intended to address a shortcoming of
[Clock Pins] in the context of a DDR controller.

Michael recalled that BIRD208 added the [Clock Pins] keyword in IBIS 7.1.  The
purpose was to inform EDA tools about the "clocking relationship" between two
pins.  For example, it enables the model maker to tell the tool or user that one
pin clocks data into another.  He said a hole in the scheme had been discovered.
For DDR, one might find there are many different clocking relationships.  One
DRAM IC might have 4 data lines strobed by a single clock.  Another variant of
the IC might have 8 data lines strobed by the same clock.  Even if the two
designs were nearly identical otherwise, this could be handled by using separate
[Component] definition.  However, for a DDR controller, this presents more of a
problem.  A single DDR controller might be configurable to support x4 or x8
DRAMs (note: not in the same simulation, but configurable ahead of time).
Having to create multiple [Component]s to support the same controller would be
clumsy and inefficient.

The new proposal would add a [Clock Group]/[End Clock Group] keyword pair.  The
pair encapsulates a [Clock Pins] keyword and enables a clock group name to be
specified for that particular instance.  Multiple [Clock Group] pairs could be
specified in the same [Component] to allow multiple uniquely named instances of
[Clock Pins] to be provided.  The clock group name entries would be used in the
same way as a [Model Selector] and allow EDA tools to present users with a list
of [Clock Pins] options from which to select.

Michael said that overall the proposal was very simple.  There is no change at
all to existing usage of [Clock Pins].  This merely adds an additional level of
hierarchy to specify multiple named configurations.

Walter said he understood the motivation for this proposal. He observed that the
fundamental issue was that we had previously created the concept of a "group" as
a configuration selector, for example, [Interconnect Model Group]s,
[Model Selector]s, etc.  He said he would probably support this proposal too,
but he suggested an alternate possibility.  He said that instead of adding a new
group keyword every time we need one, we might consider an #ifdef style syntax.
With #ifdef style syntax a configuration file could be provided to define which
portions of the model were used.  He said this might be a more general way to
handle the issue.  Michael said he would be willing to consider the idea of
#ifdefs.

Michael noted that the [Clock Group] proposal would make [Clock Pins] the first
keyword that could appear at two different levels in the hierarchy.
[Clock Pins] could then appear directly under [Component], or it could appear
inside a [Clock Group]/[End Clock Group].  Arpad said that to be consistent with
other group keywords, the [Clock Pins] themselves should be named (and multiple
instances allowed), and the names would then be listed in the [Clock Group].
Michael agreed and said that would have been his first choice.  However, he had
been concerned that it would be more trouble to modify an existing keyword's
definition.  However, he was open to the suggestion.

Bob asked if Michael's intention was to get this included in IBIS 7.2.  Michael
said that would be ideal, but he acknowledged that the proposal was new and not
quite ready for consideration.  He said he would not push to have it included in
IBIS 7.2.

Arpad said Walter's #ifdef proposal was interesting.  He asked: If we were to
add #ifdef would we want to rewrite existing [Model Selector] and group selector
keyword sections to use the #ifdef style?  Walter said we wouldn't need to touch
the existing keywords at all.

Dual-Input AMI Model Questions:
Michael shared a presentation, "Questions on Creating Clocked (Dual-Input) Rx
AMI Models."  It presented a flow chart of an EDA tool's parsing/analysis flow
for a clock-forwarded IBIS-AMI Rx model.  Michael thought there might be the
possibility of ambiguities.

Michael observed that an EDA tool now has to parse all the way down [Model]->
[Algorithmic Model]->.ami file->Rx_Use_Clock_Input, to determine if a particular
model is a dual input model.  Therefore, it must parse to that level and have
the [Clock Pins] keyword provided in order to understand the pin-level
connectivity.

Michael presented an example (slide 5) in which the [Clock Pins] keyword was
provided and both the pins (clock pin and clocked pin) on one line were defined
(via the [Pin] keyword) to use the same dual input Rx AMI model.  He expressed
concern that this might imply that a single instance of the model handled both
pins.  Walter and others said no, if an AMI model is specified for each pin,
then each pin gets its own instance, even if the same [Model] is specified for
both pins.

Randy noted one other special case.  It would be possible to specify no AMI
model for the clock pin at all.  In that case, only the AMI model for the data
pin is instantiated, and the EDA tool is expected to provide a pass-through
model for the clock pin that passes its waveform data directly into the
clock_times input of the data model.  He noted that this would be legal only
if "Times" was not amongst the list of possible values for Rx_Use_Clock_Input
specified in the data model's .ami file.

Michael asked whether his example scenario would require him to create
different [Model]s for the clock and data pins in order to specify different
AMI models.  Walter said that strictly speaking, the answer was no.  He said the
same AMI model could be specified for both pins, and at simulation time the user
would select different configurations for each pin.  For example, the user would
set Rx_Use_Clock_Input to "None" for the clock model, and they would set
Rx_Use_Clock_Input to "Times" for the data pin.  Randy said this would be an
extremely cumbersome and confusing way to distribute the models.  He said such a
model would likely support equalization for the data pin, and the user would have
to shut all of that off for the clock pin, for example.  Walter agreed that this
would not be the recommended way to create and distribute the model.  He said
Michael had proposed a corner case example, and he was merely stating that it is
possible to handle that case without changes to IBIS.  Walter, Randy, and others
agreed that even if the underlying implementation of the executable model were
the same for both the clock and data pins, it would be much better to provide
different [Model]s for the two pins so the .ami file for each would be
configured for proper operation of the respective pins.  Arpad asked Michael if
he was insisting on using the same [Model] for the clock and data pins.  Michael
said he was not.  He was asking if we needed to clarify things for model makers.

Michael commented that the introduction of the Rx_Use_Clock_Input effectively
turns all AMI_GetWave functions into dual input models, and the value "None" is
the special case that specifies legacy single-input operation.  Walter agreed,
but clarified that the model has to be written to handle dual input operation,
and Rx_Use_Clock_Input (if it exists) advertises what the model is capable of.
Walter said he didn't think we needed to add anything to the specification to
clarify things for model makers.

Michael said he would send his slides to the ATM list.  He asked that people
consider how an example setup of his scenario would work for the "Wave" case
only.  He said he wanted to make sure we hadn't missed anything.

- Randy: Motion to adjourn.
- Curtis: Second.
- Arpad: Thank you all for joining.

AR: Michael to send his Dual Input Rx Questions presentation to the ATM list.
    
-------------
Next meeting: 16 August 2022 12:00pm PT
-------------

IBIS Interconnect SPICE Wish List:

1) Simulator directives
